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Summary 


This paper describes the transport delays associated with flight simulation programs currently 
operating at the NASA Langley Research Center (LaRC). Formulas are presented for calculating 
a rough estimate of the transport delay for a particular simulation. Various simulation programs 
that used the Flight Simulation Facility (FSF) at LaRC, during the period of October 1993 to 
March 1994, were tested to determine the transport delays associated with the simulation 
program and any associated hardware. Several simulators were tested, including the Differential 
Maneuvering Simulator (DMS), the Visual Motion Simulator (VMS), and the Transport System 
Research Vehicle (TSRV). 


Introduction 


Research conducted at LaRC’s FSF requires the simulation to match the real-world vehicle. Each 
simulation program contains math models that are used to describe the performance envelope of 
a particular vehicle. Since real-world delays are already included in the vehicles math model any 
additional delays due to the simulation would be considered superfluous. It is desirable to 
minimize these delays, defined as transport delays, as much as possible. Current studies show 
that acceptable transport delays are approximately 1 50 milliseconds (ms) for transport 
simulations ’ and 1 00 ms for high performance aircraft . This paper documents the transport 
delays associated with most of the research programs using the FSF. 


Simulator Descriptions 

A typical simulation requires several pieces of hardware and software, operating in conjunction, 
to generate the appropriate cues to the pilot. In general, necessary components include a cockpit, 
a real-time computer, a real-time control console, an image generator, cockpit instrumentation, 
and communications equipment. Fighter simulators may also require target projectors. Three of 
the major simulators located at the FSF are the Differential Maneuvering Simulator (DMS) 4 , the 
Visual Motion Simulator (VMS) 5 , and the Transport System Research Vehicle (TSRV) 6 . The 
DMS is used mostly for high performance and military aircraft research; the VMS is used for 
subsonic and hypersonic vehicles, high performance aircraft, and helicopter research, and the 
TSRV is used for subsonic transport related research. Each simulator uses the central facility 
concept of the FSF. In this concept, major simulation hardware components are shared among 
multiple simulations to increase productivity. The major components that are shared among the 
simulations are real-time control consoles, real-time computers, the Calligraphic/Raster Display 
System (CRDS), and the Computer-Generated Image (CGI) system. 



Shared Resources 


There are four real-time control consoles in the FSF. Each console can support an independent 
simulation. Prior to the startup of a simulation program the real-time operator schedules the 
equipment that will be necessary for a particular simulation. The scheduled hardware 
communicates with the real-time simulation program via a fiber optic Local Area Network (LAN) 
called the Advanced Real-Time Simulation System (ARTSS) . Each simulation program can 
execute on one, or more, Central Processing Units (CPU) on one of two CONVEX super 
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computers . Since all of the simulations currently in production at the FSF execute on a single 
CPU this was the only CPU configuration tested. The cockpit instrumentation in the DMS, 
VMS, and TSRV is drawn by the CRDS onto Heads-Down-Display (HDD) monitors mounted 
in each cockpit. The CRDS is composed of three Terabit Eagle 1000 systems. Typically only 
one CRDS subsystem is required for a simulation. Each simulator uses one of two Evans and 
Sutherland CT6 eyepoints to render the out-the- window scene. In the DMS, the scene is 
projected onto the inside surface of a sphere with a resolution of approximately 13 arc 
minutes/pixel. The CGI scene is rendered for the VMS and the TSRV on XKD 8000 monitors, 
through collimating optics. The resolution of these displays is approximately 4 arc 
minutes/pixel. 

Differential Maneuvering Simulator 

The DMS consists of two 40 foot diameter spheres with a fighter cockpit at the center of each 
sphere. Each cockpit has a McFadden control loader, throttles, and various switches that the 
pilot can use to provide inputs to the simulation. The pilot receives information on the other 
aircraft's position via an image of a target projected onto the sphere wall. Each sphere’s target is 
rendered with a Silicon Graphics Incorporated (SGI) 320 VGX system and is then projected onto 
the sphere using a monochrome General Electric (GE) light valve and a McDonnell Douglas 
mirror projection system. The resolution of the projected target is approximately 1024 TV lines. 
Each DMS cockpit uses the CRDS to drive three calligraphic monitors and one Heads-Up- 
Display (HUD) for cockpit instrumentation. The CGI image, for the external visual scene, is 
projected onto the sphere’s surface with GE color light valves. 

Visual Motion Simulator 


The VMS is a generic cockpit mounted on a 6-degree-of-freedom motion base platform. The 
cockpit provides two McFadden control loaders; a left side-arm for the pilot and a center stick 
for the co-pilot. The co-pilot's seat has a collective mounted to it to allow for helicopter 
simulations. Throttles and other various switches are used to provide additional control inputs 
to the simulation program. The CRDS is used for displaying the cockpit’s instrumentation onto 
six monitors. In addition, a CRDS display can be mixed with the CGI system to provide a HUD 
in the cockpit. The CGI system drives four XKD monitors to provide the out-the-window 
scenery. 
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Transport Systems Research Vehicle 


The TSRV cockpit is a research cockpit configured as a modified research 737 cockpit. The 
cockpit uses McFadden side-arm control loaders for both the pilot and co-pilot. As in the other 
simulators, throttles and various switches provide additional control inputs to the simulation 
program. The CRDS provides cockpit instrumentation on all eight monitors in the TSRV 
cockpit. A HUD can also be displayed by mixing a CRDS display with the CGI system. The 
CGI system drives four XKD monitors to provide the out-the-window scenery. 


Experimental Setup 

The transport delay for each simulation real-time program was measured using a time based 
analysis technique. References 9 and 10 provide detailed explanations of the measurement setup. 
Each simulator uses a baseline program that is modified to provide the base control system for a 
particular vehicle. The baseline program for each simulator was modified to monitor a discrete 
switch at the input of an Analog-to-Digital Converter (ADC) for the control loader. The pitch 
axis was used on the DMS and the roll axis was used for the VMS and TSRV. By modifying the 
baseline program, these changes are available to each vehicle using the program. Each vehicle was 
then trimmed to a stable flight condition and the simulation program placed in the operate mode. 
Next the switch was toggled, and the time for the various hardware subsystems to respond to the 
input was measured with a logic analyzer. 


Transport Delays 

This test does not verify the fidelity of the simulation. Rather it is useful to determine if the 
math model and the simulation hardware is responding as quickly as possible to an input. 
Therefore, this test only measures the onset of a response. Most of the math models begin to 
respond within one frame of the input, therefore; most programs will have approximately the 
same transport delay. The transport delay due to the simulation implementation is a function of 
the simulation update rate. The inputs are read at the beginning of each frame. The program then 
processes these inputs to generate the next state information for the various math model 
subsystems and simulation output devices. The data for the CT6, SGI and the target servo is 
sent, asynchronously, to the respective devices as soon as the necessary information is generated. 
This usually occurs within 5 to 10 milliseconds (ms) from the beginning of the frame on the 
CONVEX, and depends mostly on the length of the vehicles math model code. The data for the 
CRDS is sent asynchronously at the beginning of the next frame so that any remaining equations 
can be calculated. Outputs to synchronous devices are generated at the end of a simulation frame. 
Cockpit Input/Output (I/O) is usually passed as synchronous data. The transport delays 
presented are averages based on 20 measurements. These averages give an estimate of the amount 
of time it takes for a particular system to begin responding to the pilot's input. Due to the highly 
asynchronous nature of the transmission paths to different pieces of equipment, these numbers 
are only accurate to within ±5 ms. However, this does give an indication as to whether 
improvements should be made to the model or if an error has been introduced in the program. 
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PMS Transport Delays 


The transport delays that were measured for the DMS were the delays associated with the CGI, 
SGI, and the CRDS. The time from the switch toggle to the completion of the first field of raster 
video of the CGI and the SGI was measured. Also, the time from the switch toggle to the 
completion of the calligraphic CRDS display was measured. The transport delay for the analog 
target generator servo was measured using a sinusoidal input rather than the discrete step 
generated by a switch. The sinusoidal input was patched into the pitch axis and was plotted 
against the servo output at various frequencies to determine the servo response. The following 
table shows the transport delays for simulation vehicles tested. 


Program Name (Update Rate) 

Switch to CGI 
Complete (ms) 

Switch to CRDS 
Complete (ms) 

Switch to SGI 
Complete (ms) 

F- 18 Baseline (31.25 Hz) 

113 

123 

105 

F-18 Baseline (62.5 Hz) 

100 

94 

98 

SUPFIT/TIGRES (31.25 Hz) 

116 

127 

107 


112 

128 

106 

AGILE (40 Hz) 

113 

118 

103 

HANG (40 Hz) 

113 

118 

103 

HARV (40 Hz) 

112 

117 

107 

HAV2 (33 Hz) 

113 

123 

105 


115 

121 

106 

F-16XL Baseline (62.5 Hz) 

101 

99 

94 


The transport delay for the target servo is shown below. The servo was tested at several 
frequencies to yield a steady state delay at those frequencies. 


Frequency (Hz) 

Transport Delay (ms) 

0.3 

37 

0.5 

40 

0.7 

44 

1.0 

47 

1.5 

50 

2.0 

70 

2.5 

80 

3.0 

95 

5.0 

100 ! 
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VMS Transport Delays 


The transport delays measured for the VMS were the delays associated with the CGI, and the 
CRDS. The following table shows the transport delay data for the respective jobs tested. 


Program Name (Update Rate) 

Switch to CT6 
Complete (ms) 

Switch to CRDS 
Complete (ms) 

GHS (32 Hz) 

144 

159 

HSCT (32 Hz) 

139 

156 

PLS (32 Hz) 

109 

133 


From the data above the PLS program measures about a frame faster than the GHS, and HSCT 
programs. Upon further investigation, it was discovered that the control laws for the GHS and 
HSCT vehicles do not begin to respond to inputs until more than 30 ms after an input is 
detected. 

TSRV Transport Delays 

The transport delays that were measured for the TSRV were the delays associated with the CGI, 
and the CRDS. The following table shows the transport delay data for the respective jobs 
tested. 


Program Name (Update Rate) 

Switch to CT6 
Complete (ms) 

Switch to CRDS 
Complete (ms) 

CC - Baseline (32 Hz) 

111 

135 

TEEM (32 Hz) 

108 

137 

IIC (32 Hz) 

113 

137 

CWIN (32 Hz) 

111 

135 

HSS (32 Hz) 

114 

138 

WCP (32 Hz) 

107 

135 

WCP-DH (32 Hz) 

108 

133 


Data Analysis 

The transport delay measured for the various simulation components is usually a function of the 
update rate of the real-time simulation program and each subsystem. In general, the faster the 
real-time program and the different subsystems operate, the lower the overall transport delay. 
The theoretical average transport delay, for the CGI, CRDS and the SGI, can be calculated using 
the following equations: 

tdcgi « (0.5*h) + tdprog + tdarts + cgi 

tdcrds ~ (15*h) + tdprog + tdarts + pipe*update 

td S gi * (0.5*h) + tdp ro g + tdarts + sgi*(1.5*ceil(update/sgi) + 1) 
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Where: 


h = simulation step size (ms) 
tdprog = time in program (ms) 
tdarts = transmission time (ms) 

cgi = 92 ms, the time required for the CGI to sample and render the image 

pipe = 5.5, the number of pipeline stages in the CRDS 

update = the update rate for the graphics program (ms) 

sgi = 16.7 ms, the frame update on the SGI 

ceil(x) = smallest integer > x 

In some systems, as the update rate is increased, other factors in the system become more 
prevalent and reduce the effectiveness of the system. For example, the CRDS can operate with 
display update rates up to 120 Hz. The theoretical transport delay of the CRDS should be 
approximately 5.5 times the update rate or 46 ms. If a 32 Hz simulation program were driving a 
CRDS operating at 120 Hz one would calculate an anticipated transport delay » 103 ms. 
However, the measured transport delay was an average 19 ms longer (or « 122 ms). This is 
caused by excessive collisions occurring on the CRDS I/O buses. At the very high update rates, 
the graphics pipeline uses a high percentage of the bus bandwidth. This leaves less time for 
communications data from the real-time simulation program to be transferred on the bus. The 
SGI system follows the theoretical equation fairly well, however, the update rate of the graphics 
program should be measured with the swap_buffer call commented out. This will reveal the 
actual refresh rate and the amount of idle time before the system redraws the screen. The SGI 
systems can suffer from the excessive delays due to the buses and CPU usage. The SGI’s used 
for the target projectors are single CPU systems. Therefore, high update rates coupled with high 
graphics update rates can have deleterious effects. However, this phenomena was not noticed 
until the real-time update rate exceeded 1 60 Hz. The CGI times are very stable, since the system 
always updates at 50 Hz; therefore, the theoretical calculations agree very well with the measured 
times. The CGI behaved as the theoretical equation predicted throughout range of possible real- 
time update rates. 

From the data above one can see that the faster the real-time simulation program update rate, the 
lower the transport delay. This is mostly due to the elimination of slack CPU time on the 
CONVEX. Since the CONVEX CPU’s are very powerful, most real-time simulation programs 
execute within the first 5 ms of the real-time frame. By increasing the frame rate, through 
lowering the frame time, the amount of idle CPU time is greatly reduced. This is especially true 
for the CRDS transport delay since the program must wait an entire frame before the data is sent 
to the CRDS. This is because several variables to be displayed must be calculated at the 
beginning of the next frame before they are sent to the CRDS. Although the increase in frame rate 
reduces the transport delay, the benefits diminish as the frame rate is increased. For example, if 
the simulation program were to operate at 120 Hz the time saved from the 62.5 Hz transport 
delay would only be an additional 5 ms. Asa general rule of thumb, real-time simulation 
programs operating above 60 Hz should be sufficient to minimize excess slack CPU time. If 
additional reductions are necessary, other methods should be employed. 
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Transport Delays Reduction 


Generally, there are two methods available to accomplish additional transport delay reductions. 
The first is to employ predictor algorithms in the body of the simulation programs. This is not 
considered an acceptable solution due to the unpredictable nature of the simulations in the FSF. 
The second method used to reduce the transport delays requires the replacement of existing 
equipment with faster equipment. The Advanced Computer Generated Image (ACGI) system, 
scheduled for delivery in August 1994, will reduce the transport delay to the out-the-window 
scene by about 25 ms. The TSRV is being upgraded with raster monitors and SGI Onyx systems 
to drive the cockpit instrument information. This will reduce the transport delay for the TSRV 
HDD by approximately 30 ms. 


Conclusions 


The transport delay measured for the various simulation components was consistent from 
program to program. The average transport delay for a simulator is one-half the programs update 
rate plus the time to calculate the math models next state and the delay due to the output 
hardware. A program that operates at 3 1 .25 Hz will exhibit average transport delays from 100 
to 1 1 5 ms to the CGI and from 1 1 5 to 1 40 ms to the CRDS. Further improvements can be made 
by operating at faster update rates, upgrading the simulator hardware, or improving the display 
update rates. 
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